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(54) Packet processor with programmable application logic 



(57) A data communication switch includes a back- 
plane and multiple packet switching controllers. At least 
one packet switching controller includes programmable 
application logic for generating application data for a 
packet. The application logic is contained in key builder 
and lookup table of an application engine. The key build- 



er contains one or more schema programs for generat- 
ing keys and key controls using classification informa- 
tion and header data of inbound packets. The schema 
programs can be loaded onto the key builder during fab- 
rication of the packet switching controller or in field. The 
keys and key controls are used to lookup the application 
data from the lookup table. 
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Description 



SUMMARY 



CROSS-REFERENCE TO RELATED APPLICATIONS 

[0001] The present application claims the priority of 5 
U.S. Provisional Application No. 60/206,617 entitled 
"System and Method for Enhanced Line Cards" filed 
May 24, 2000, U.S. Provisional Application No. 
60/206,996 entitled "Flow Resolution Logic System and 
Method" filed May 24, 2000 and U.S. Provisional Appli- 10 
cation No. 60/220,335 entitled "Programmable Packet 
Processor" filed July 24, 2000, the contents of all of 
which are fully incorporated by reference herein. The 
present application contains subject matter related to 
the subject matter disclosed in U.S. Patent Application 15 
No. 09/679,138 entitled 'Tuple-Based Lookup Scheme 
for Packet Switching Node" filed October 3, 2000 and 
U.S. Patent Application (Attorney Docket No. 
40029/JEJ/X2/1 34021) entitled "Programmable Packet 
Processor with Flow Resolution Logic" filed December 20 
28, 2000, the contents of both of which are fully incor- 
porated by reference herein. 
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[0002] Many conventional packet switching control- 
lers rely on fixed, i.e. non-programmable, logic to make 
the lion's share of packet decisions. Programmable log- 
ic has been relied on, if at all, to make decisions for "ex- 
ceptional" packets. Such "hardwired" controllers, which 30 
make fixed logic the bulwark of decision-making and rel- 
egate programmable logic to at most a collateral role, 
have generally supported relatively high forwarding 
speeds but also a severely limited feature set. Feature 
limitations have been imposed by the general require- 35 
mentof including discrete fixed logic for each application 
the controller is expected to support. This general re- 
quirement of application-specific fixed logic has limited 
the number of applications the controller can support 
and has made it difficult to "field upgrade" the controller *o 
to add application support. Instead, new application 
support has typically required a hardware upgrade. 
[0003] Due to the relative inflexibility of hardwired 
switching controllers, controllers reliant on programma- 
ble logic for routine packet decision-making (particularly 45 
controllers having multiple programmable processors) 
have been given more attention in recent years. Such 
multiprocessor controllers, sometimes called "network 
processors", can typically support a variety of applica- 
tions and are typically more amenable to field upgrades so 
due to their programmable nature. 
[0004] The simultaneous multi-application support 
provided by network processors makes it desirable for 
application logic to effectuate distinct applications in re- 
sponse to different packet conditions. Therefore, it is de- 55 
sirable to provide an efficient application logic for a net- 
work processor that can provide different application da- 
ta to different packet conditions or types. 



[0005] In one embodiment of the present invention, a 
packet processing element is provided. The packet 
processing element has a plurality of schemata pro- 
grammed thereon. Classification information for the 
packet is used to select at least one schema, and the 
selected schema is used to produce application data for 
the packet. 

[0006] In another embodiment of the present inven- 
tion, a method of producing application data for a packet 
is provided. The method uses a packet processing ele- 
ment having a plurality of schemata programmed ther- 
eon. At least one schema is selected using classification 
information for the packet, and the application data for 
the packet is produced using the selected schema. 
[0007] In yet another embodiment of the present in- 
vention, a packet switching controller is provided. The 
packet switching-controller includes a processing en- 
gine. The processing engine includes an element for 
building a key using classification information for a pack- 
et and a lookup table containing one or more schemata. 
The key is used to select one of the schemata for the 
packet, and the selected schema provides application 
data for the packet. 

[0008] In still another embodiment of the present in- 
vention, a method of producing application data for a 
packet is provided. A key is built using classification in- 
formation for the packet. Then a schema is selected for 
the packet from a lookup table containing one or more 
schemata. The application data is read from the select- 
ed schema. 

[0009] In a further embodiment of the present inven- 
tion, a data communication switch having a backplane 
and a plurality of packet switching controllers intercon- 
nected over the backplane is provided. At least one 
packet switching controller includes an application en- 
gine having a plurality of schemata programmed there- 



BRIEF DESCRIPTION OF THE DRAWINGS 

[0010] These and other aspects of the invention may 
be understood by reference to the following detailed de- 
scription, taken in conjunction with the accompanying 
drawings, which are briefly described below. 

FIG. 1 illustrates a network environment including 

a packet switching node in which one embodiment 

of the present invention is used; 

FIG. 2 is a block diagram of a switching interface in 

one embodiment of the present invention; 

FIG. 3 is a block diagram of a programmable packet 

switching controller in one embodiment of the 

present invention; 

FIG. 4 is a block diagram of an application engine 
of a programmable packet switching controller in 
one embodiment of the present invention; 
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FIG. 5 is a schema table contained in a lookup table 
of an application engine in one embodiment of the 
present invention; and 

FIG. 6 is a flow diagram illustrating a process of 
identifying application data in one embodiment of 5 
the present invention. 

DETAILED DESCRIPTION 

I. Overview w 



[0011] In FIG. 1, network environment including a 
packet switching node 10 is illustrated. The packet 
switching node. may also be referred to as a switch, a 
data communication node or a data communication is 
switch. The packet switching node 1 0 includes switching 
interfaces 14, 16 and 18 interconnected to respective 
groups of LANs 30, 32 : 34, and interconnected to one 
another over data paths 20, 22, 24 via switching back- 
plane 12. The switching backplane 12 preferably in- 20 
eludes switching fabric. The switching interfaces may al- 
so be coupled to one another over control paths 26 and 
28. 

[0012] The switching interfaces 14, 16, 18 preferably 
forward packets to and from their respective groups of 25 
LANs 30, 32, 34 in accordance with one or more oper- 
ative communication protocols, such as, for example, 
media access control (MAC) bridging and Internet Pro- 
tocol (IP) routing. The switching node 10 is shown for 
illustrative purposes only. In practice, packet switching 30 
nodes may include more or less than three switching 
interfaces. 

[0013] FIG. 2 is a block diagram of a switching inter- 
face 50 in one embodiment of the present invention. The 
switching interface 50 may be similar, for example, to 35 
the switching interfaces 1 4, 1 6, 1 8 of FIG. 1 . The switch- 
ing interface 50 includes an access controller 54 cou- 
pled between LANs and a packet switching controller 
52. The access controller 54, which may, for example, 
include a media access controller (MAC), preferably re- 40 
ceives inbound packets off LANs, performs flow-inde- 
pendent physical and MAC layer operations on the in- 
bound packets and transmits the inbound packets to the 
packet switching controller 52 for flow-dependent 
processing. The access controller 54 preferably also re- 4s 
ceives outbound packets from the packet switching con- 
troller 52 and transmits the packets on LANs. The ac- 
cess controller 54 may also perform physical and MAC 
layer operations on the outbound packets prior to trans- 
mitting them on LANs. so 
[0014] The packet switching controller 52 preferably 
is programmable for handling packets having wide va- 
riety of communications protocols. The packet switching 
controller 52 preferably receives inbound packets, clas- 
sifies the packets, modifies the packets in accordance 55 
with flow information and transmits the modified packets 
on switching backplane, such as the switching back- 
plane 1 2 of FIG. 1 . The packet switching controller 52 



preferably also receives packets modified by other 
packet switching controllers via the switching backplane 
and transmits them to the access controller 54 for for- 
warding on LANs. The packet switching controller 52 
may also subject selected ones of the packets to egress 
processing prior to transmitting them to the access con- 
troller 54 for forwarding on LANs. 
[0015] FIG. 3 is a block diagram of a programmable 
packet switching controller 100 in one embodiment of 
the present invention. The programmable packet 
switching controller 1 00, for example, may be similar to 
the packet switching controller 52 of FIG. 2. The pro- 
grammable packet switching controller 100 preferably 
has flow resolution logic for classifying and routing in- 
coming flows of packets. Packet switching controllers in 
other embodiments may include more or less compo- 
nents. For example, a packet switching controller in an- 
other embodiment may include a pattern match module 
for comparing packet portions against a predetermined 
pattern to look for a match. The packet switching con- 
troller in yet another embodiment may include an edit 
module for editing inbound packets to generate out- 
bound packets. Further, packet switching controllers in 
still other embodiments may include other components, 
such as, for example, a policing engine, in addition to or 
instead of the components included in the programma- 
ble packet switching controller 100. 
[0016] Due to its programmable nature, the program- 
mable packet switching controller preferably provides 
flexibility in handling many different protocols and/or 
field upgradeability. The programmable packet switch- 
ing controller may also be referred to as a packet switch- 
ing controller a switching controller a programmable 
packet processor, a network processor, a communica- 
tions processor or as another designation commonly 
used by those skilled in the art. 
[001 7] The programmable packet switching controller 
1 00 includes a packet buffer 1 02, a packet classification 
engine 104, and an application engine 106. The pro- 
grammable packet switching controller 100 preferably 
receives inbound packets 108. The packets may in- 
clude, but are not limited to, Ethernet frames, ATM cells, 
TCP/IP and/or UDP/IP packets, and may also include 
other Layer 2 (Data Link/MAC Layer), Layer 3 (Network 
Layer) or Layer 4 (Transport Layer) data units. For ex- 
ample, the packet buffer 1 02 may receive inbound pack- 
ets from one or more Media Access Control (MAC) Lay- 
er interfaces over the Ethernet. 

[0018] The received packets preferably are stored in 
the packet buffer 102. The packet buffer 102 may in- 
clude a packet FIFO for receiving and temporarily stor- 
ing the packets. The packet buffer 102 preferably pro- . 
vides the stored packets or portions thereof to the pack- 
et classification engine 104 and the application engine 
106 for processing. 

[001 9] The packet buffer 1 02 may also include an edit 
module for editing the packets prior to forwarding them 
out of the switching controller as outbound packets 118. 
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The edit module may include an edit program construc- 
tion engine for creating edit programs real-time and/or 
an edit engine for modifying the packets. The application 
engine 106 preferably provides application data 116, 
which may include a disposition decision for the packet, 
to the packet buffer 1 02, and the edit program construc- 
tion engine preferably uses the application data to cre- 
ate the edit programs. The outbound packets 118 may 
be transmitted over a switching fabric interface to com- 
munication networks, such as, for example, the Ether- 
net. 

[0020] The packet buffer 1 02 may also include either 
or both a header data extractor and a header data 
cache. The header data extractor preferably is used to 
extract one or more fields from the packets, and to store 
the extracted fields in the header data cache as extract- 
ed header data. The extracted header data may include, 
but are not limited to, some or all of the packet header. 
In an Ethernet system, for example, the header data 
cache may also store first N bytes of each frame. 
[0021] The extracted header data preferably is pro- 
vided in an output signal 1 1 0 to the packet classification 
engine 104 for processing. The application engine may 
also request and receive the extracted header data over 
an interface 114. The extracted header data may in- 
clude, but are not limited to : one or more of Layer 2 MAC 
addresses, 802.1 P/Q tag status, Layer 2 encapsulation 
type, Layer 3 protocol type, Layer 3 addresses, ToS 
(type of service) values and Layer 4 port numbers. In 
other embodiments, the output signal 110 may include 
the whole inbound packet, instead of or in addition to 
the extracted header data. In still other embodiments, 
the packet classification engine 1 04 may be used to edit 
the extracted header data to be placed in a format suit- 
able for use by the application engine, and/or to load 
data into the header data cache. 
[0022] The packet classification engine 1 04 prefera- 
bly includes a programmable microcode-driven embed- 
ded processing engine. The packet classification engine 
104 preferably is coupled to an instruction RAM (IRAM) 
(not shown). The packet classification engine preferably 
reads and executes instructions stored in the IRAM. In 
one embodiment, many of the instructions executed by 
the packet classification engine are conditional jumps. 
In this embodiment, the classification logic includes a 
decision tree with leaves at the end points that prefera- 
bly indicate different types of packet classifications. Fur- 
ther, branches of the decision tree preferably are select- 
ed based on comparisons between the conditions of the 
instructions and the header fields stored in the header 
data cache. In other embodiments, the classification 
logic may not be based on a decision tree. 
[0023] In one embodiment of the present invention, 
the application engine 106 preferably has a pipelined 
architecture wherein multiple programmable sub-en- 
gines are pipelined in series. Each programmable sub- 
engine preferably performs an action on the packet, and 
preferably forwards the packet to the next programma- 



ble sub-engine in a "bucket brigade" fashion. The packet 
classification engine preferably starts the pipelined 
packet processing by starting the first programmable 
sub-engine in the application engine using a start signal 
5 112. The start signal 112 may include identification of 
one or more programs to be executed in the application 
engine 1 06. The start signal 1 1 2 may also include pack- 
et classification information. The programmable sub -en- 
gines in the application engine preferably have direct ac- 
10 cess to the header data and the extracted fields stored 
in the header data cache over the interface 114. 
[0024] The application engine may include other 
processing stages not performed by the programmable 
sub-engines : however, the decision-making stages 
15 preferably are performed by the programmable sub-en- 
gines to increase flexibility. In other embodiments, the 
application engine may include other processing archi- 
tectures. In still other embodiments, the application en- 
gine may use a" Tuple-based lookup scheme to identify 
20 application data, such as, for example, the scheme used 
in U.S. Patent Application No. 09/679,138 entitled "Tu- 
ple-Based Lookup Scheme for Packet Switching Node." 

II. Programmable Application Logic 

25 

[0025] FIG. 4 is a block diagram of an application en- 
gine 150 in a programmable packet switching controller 
in one embodiment of the present invention. The appli- 
cation engine 150 : for example, may be similar to the 
30 application engine 1 06 of FIG. 3. The application engine 
150 includes a key builder 152 and a lookup table 154. 
[0026] The key builder 1 52 preferably receives packet 
classification information 156 from a packet classifica- 
tion engine, such as, for example, the packet classifica- 
35 tion engine 1 04 of FIG. 3. The key builder 1 52 preferably 
also receives extracted header data 1 58 from a packet 
buffer, such as, for example, the packet buffer 102 of 
FIG. 3. More particularly, the key builder preferably re- 
trieves extracted header data stored in a header data 
40 cache included in the packet buffer. 

[0027] The key builder 1 52 preferably contains one or 
more schema programs. The schema programs prefer- 
ably are loaded into the key builder 152 using an input 
signal 160. The schema programs preferably are used 
45 to identify key data and key control data for inbound 
packets. The key builder 152 preferably uses the clas- 
sification information, the extracted header data and the 
schema programs to build one or more search keys to 
compare against entry keys associated with application 
so data contained in the lookup table 154. 

[0028] The association information between the ap- 
plication data and the entry keys preferably are con- 
tained in the lookup table 1 54 in the form of one or more 
schema tables. A key control may also be used during 
55 the selection of the application data. The key control, 
such as, for example, IP subnet mask, preferably affects 
how the search keys from the key builder are compared 
to the entry keys in the schema tables. The key controls, 
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when used, preferably are provided together with the 
search keys 162. 

[0029] FIG. 5 is a schema table 200 in the lookup table 
154 in one embodiment of the present invention. The 
schema table 200, which may also be referred to as a 
search table, preferably includes various different types 
of schemata. The column 202 illustrates various differ- 
ent schema types. It is to be noted that the column 202 
is shown for illustrative purposes only, and may not be 
a part of an actual schema table. The schema table 200 
illustrates seven schema types, each type being repre- 
sented by a row in the table. Thus, Types I through VII 
correspond, respectively, with the rows 210, 212, 214, 
21 6, 21 8, 220 and 222. In addition, entry keys, key con- 
trols and application data correspond, respectively, with 
the columns 204, 206 and 208. In other embodiments, 
the schema tables may contain entry keys, key controls 
and application data associated with more or less than 
seven schema types. 

[0030] The schema Type 1210 preferably is a type In 
which source information is used for searching. The en- 
try key in Type I includes Virtual Local Area Network 
(VLAN) ID, application ID (APP ID), and an invalid bit 
(I). The VLAN ID is the source VLAN for the packet, e. 
g., frame, being considered, and preferably allows for 
identification of the customer. The APP ID preferably al- 
lows for awareness of the application being run per cus- 
tomer. In practice, the APP ID may be identified in a 
packet buffer, such as, for example, the packet buffer 
102 of FIG. 3. In one embodiment of the present inven- 
tion, the APP ID is a 7-bit index, which has been mapped 
from 1024 TDP/UDP ports. For example, the APP ID 
may identify Hyper Text Transfer Protocol(HTTP) appli- 
cation. In other embodiments, the APP ID may have 
more or less than seven bits, and/or may be identified 
in a different manner. The invalid bit, when set, prefer- 
ably indicates entries that are in the process of being 
deleted from the schema table. 

[0031 ] The key control A of the schema Type I prefer- 
ably is a control bit that preferably enables masking out 
of the APP ID field from the entry key. The key control 
A preferably is not supplied by the key builder as a part 
of the search key. The key control A preferably is used 
during the search process when comparing the search 
key to the entry key. If the key control A Is the same as 
the VLAN default data, the masking of the APP ID field 
may not be used. The setting of the key control A pref- 
erably results in the search process ignoring the APP 
ID field for the entry being looked up. This way, the key 
control A preferably allows VLAN with unknown appli- 
cations to be expressed. 

[0032] For example, suppose VLAN 6 is the source of 
packets, and packets from VLAN 6 need treatment X. 
This would be expressed in the schema table as an en- 
try, {Key = (VLAN=6, APP ID=0), Control = (A=1), Data 
= X}. The setting of the control bit A (i.e., A=1) in this 
case indicates that the APP ID is to be ignored. There- 
fore, in this situation, any search key presented to the 
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search process with VLAN=6 and any APP ID preferably 
matches this entry. 

[0033] For another example, suppose HTTP packets 
from VLAN 6 require different treatment, treatment Y. 
This would then be expressed in the schema table as 
an entry, {Key = (VLAN=6, APP ID=HTTP), Control = 
(A=0), Data = Y). Since A is not set {i.e., A=0) in this 
case, the APP ID is valid for this entry. Therefore, in this 
situation, only HTTP packets preferably are matched by 
1 this entry. 

[0034] In one embodiment of the present invention, 
the schema table preferably is implemented in such a 
way that the best matching entry (i.e., the entry in the 
table with most fields matching) is selected. For exam- 
ple, in case of the above two examples, when a search 
key having VLAN=6 and APP ID=HTTP is provided, the 
entry indicating Y treatment preferably is selected over 
the entry indicating X treatment. 

[0035] The Typfc I application data preferably includes 
POLICE ID field, Color enable (COL) field, remark ena- 
ble control (RE) bit, QoS Code Point (CP) field, QoS en- 
able (Q) bit, color control (CO) bit, PAYLOAD ID field, 
Payload Control (PO) bit, Application Police enable (AP) 
bit and Accounting Format identifier (ACCT FMT) field. 
Number of bits in the application data fields of all sche- 
ma types (Types I through VII) in one embodiment of the 
present invention, for example, Police ID [17] and QoS 
CP [6], are indicated in the schema table 200. It should 
be noted that the number of bits used to represent the 
application data fields may be different in other embod- 
iments. 

[0036] The PAYLOAD ID preferably overrides the 
destination search payload when the PO bit is set. Thus, 
the PAYLOAD ID preferably allows traffic, e.g., flows or 
packets, from a particular source or from a particular 
source and application to be directed to the destination 
indicated by the PAYLOAD ID rather than as indicated 
by the destination address (DA). 
[0037] When the AP bit is set, a police ID preferably 
is derived from the APP ID. When available, a Customer 
ID (CUST ID) may also be used during the derivation of 
the police ID. The derivation of the police ID using the 
APP ID and the CUST ID preferably allows bandwidth 
policing on a per-customer, per-application basis. The 
ACCT FMT preferably indicates a particular type of ac- 
counting to be used for a particular customer. The ACCT 
FMT, for example, may be used together with the APP 
ID and/or the CUST ID to determine a type of accounting 
to be used. The POLICE ID preferably allows policing 
and/or accounting of a particular entry separate from 
that provided by policing based on the APP ID and 
CUST ID fields as indicated by the AP and ACCT FMT 
fields. 

[0038] The COL field preferably enables override of 
the QoS color (discard eligibility) value as determined 
by the flow resolution logic. The CO bit preferably ena- 
bles the use of the COL field. When enabled, the COL 
field preferably enables the discard eligibility for custom- 



5 



9 



EP1 158 724 A2 



10 



er and/or application to be specified. 
[0039] The QoS CP field preferably enables the over- 
ride of the QoS Code Point as determined by the flow 
resolution logic. This feature preferably is enabled when 
the Q bit is set. For Differentiated Services (DiffServ) 
applications, the QoS CP field, together with the COL 
field, preferably allows customer application to have a 
specific DiffServ codepoint. For non-QoS traffic, this 
feature may allow customer application traffic to be as- 
signed to a particular queue. The RE bit preferably is 
used in DiffServ applications to indicate that the DiffServ 
codepoint should be remarked in the packet. The RE bit 
may be used with other QoS fields to apply a specific 
classification to a packet, e.g., a frame. 
[0040] The schema Type II 212 preferably is a type in 
which source information is used for searching. The en- 
try key in Type II includes Virtual Local Area Network 
(VLAN) ID, application ID (APP ID), Internet Protocol 
Source Address (IPSA) and an invalid bit (I). The entry 
key in type II preferably is used to express customers 
identified by IPSA. Therefore, in schema Type II, cus- 
tomers preferably are identified by IPSA. The VLAN ID 
is the source VLAN for the packet, e.g., frame, being 
considered. The APP ID preferably allows for aware- 
ness of the application being run per customer. The 
invalid bit (I) preferably indicates entries in the schema 
table that are in the process of being deleted. 
[0041] The schema Type II preferably includes IPSA 
Mask [6] for key control . I n other embodiments, the I PSA 
Mask may have more or less than six bits. The IPSA 
Mask may include a subnet mask used to express 
Classless Inter-Domain Routing (CIDR) networks. 
[0042] The Type II application data preferably in- 
cludes check verify (CV) bit, forward action (FA) field, 
VLAN ID CHK field, POLICE ID field, Color enable 
(COL) field, remark enable control (RE) bit, QoS Code 
Point (CP) field, QoS enable (Q) bit color control (CO) 
bit PAYLOAD ID field, Payload Control (PO) bit, Appli- 
cation Police enable (AP) bit, Accounting Format iden- 
tifier (ACCT FMT) field, customer identification (CUST 
ID) field, Sniff (S1) bit, management resource (MR) bit, 
filter control (Fj bit and search-hit (HS) bit. The POLICE 
ID field, COL field, RE bit, QoS CP field, Q bit, CO bit, 
PAYLOAD ID field, PO bit, AP bit and ACCT FMT field 
preferably are similar to the corresponding fields and 
bits in the Type I application data. 
[0043] If the Type II search key does not match the 
entry keys, the packet may be dropped or it may be for- 
warded with learn event generated, based on a per-port 
control. During the learn event, the source address of 
the packet preferably is added to an address table as- 
sociated with the application engine. In other embodi- 
ments, the VLAN ID field preferably is set to zero for the 
search, and when found, the resultant VLAN ID CHK 
field preferably is compared with the VLAN ID of the 
source. If there is a mismatch in the comparison, the 
action indicated by the FA field preferably is performed. 
The FA actions may include, but is not limited to, one or 



more of drop, forward and send to management re- 
source (EMM). 

[0044] The CUST ID field preferably is used with the 
APP ID in the key to derive a police ID. which may be 
5 used for bandwidth policing on a per-customer, per-ap- 
plication basis. The S1 bit, when set 5 preferably allows 
sniffing of traffic from a certain customer or from a cus- 
tomer/application pair. The MR bit preferably indicates 
that the traffic, e.g., packets or flows, of this type should 

io be sent to EMM; The F bit preferably indicates that the 
traffic of this type should be discarded. The HS bit, the 
search hit-bit for the entry, preferably is set by the search 
engine. The HS bit preferably is used to indicate that the 
entry has been found during a search operation so that 

15 for example, when selecting entries to age-out (e.g. t to 
reclaim table space), used entries preferably are kept 
and unused entries preferably are deleted. 
[0045] The schema Type III 214 preferably is a type 
in which both source information and destination infor- 

20 mation may be used for search ing. The entry key in Type 
III includes VLAN ID, MAC Address (MAC), APP IP and 
an invalid bit (I). Using schema Type III, customers pref- 
erably are identified by MAC source address. The 
source search preferably provides source MAC learning 

25 and customer identification. Further, the destination 
search preferably provides Layer 2 Bridging. Similar to 
the schema Type I, the schema Type III includes the key 
control A for preferably enabling masking out of the APP 
ID field in the key. Thus, A control bit preferably allows 

30 masking out of the APP ID for unknown applications. 
[0046] For source lookups, the schema Type III pref- 
erably identifies customers based on their VLAN ID, 
MAC Address and APP ID. The VLAN ID preferably rep- 
resents the source VLAN for the packet, e.g. : frame, 

35 MAC preferably represents the source MAC Address, 
and APP ID preferably represents the application ID. 
When used in a destination search, the APP ID prefer- 
ably is set to zero. Then, the PAYLOAD ID of the result 
preferably indicates the forwarding vector to use; 

40 [0047] The Type III application data preferably in- 
cludes Virtual Source Port Number (V S PORT) field, 
POLICE ID field, COL field, RE bit, QoS CP field, Q bit, 
CO bit, PAYLOAD ID field, PO bit, AP bit, ACCT FMT 
field, CUST ID field, S1 bit, MR bit, F bit, HS bit, ST bit 

45 and HD bit. The POLICE ID field, COL field, RE bit, QoS 
CP field, Q bit, CO bit, PAYLOAD ID field, PO bit, AP bit, 
ACCT FMT field, CUST ID field, S1 bit, MR bit, F bit and 
HS bit preferably are similar to the corresponding fields 
and bits in the Type I and Type II application data. The 

so VS PORT field preferably represents a virtual source 
port on the flow resolution logic in one embodiment of 
the present invention. On a successful source lookup, 
the VS PORT field preferably is compared against the 
ingress port's virtual source port number, which is used 

55 for learning. 

[0048] The schema Type IV 216 preferably is a type 
in which customers preferably are identified from multi 
protocol label switching (MPLS). The PAYLOAD ID in 
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the application data preferably is used for label switch- 
ing. The entry key in Type IV includes VLAN ID, LABEL 
and an invalid bit (I). The VLAN ID preferably represents 
source VLAN for the packet, e.g., frame. The LABEL 
field preferably includes the first MPLS label. The invalid 
bit (I) preferably is used to indicate entries of the schema 
table in the process of being removed. In this embodi- 
ment, key control field is not used with the schema Type 
IV. In other embodiments, one or more key control fields 
may be used. 

[0049] The Type IV application data preferably in- 
cludes Valid Label (VL) field, L3 Protocol (L3 PROTO) 
field, POLICE ID field, COL field, RE bit, QoS CP field, 
Q bit, CO bit, PAYLOAD ID field, PO bit, AP bit, ACCT 
FMT field, CUST ID field, S1 bit, MR bit, F bit, HS bit, 
and HD bit. The POLICE ID field, COL field, RE bit, QoS 
CP field, Q bit, CO. bit, PAYLOAD ID field, PO bit, AP 
bit ACCT FMT field, CUST ID field, S1 bit, MR bit, F bit, 
HS bit and HD bit preferably are similar to the corre- 
sponding fields and bits in the Type I, Type II and Type 
III application data. 

[0050] The VL field. may be used to indicate that the 
label is dead and should be popped. In this case, the 
next search preferably is done on the following label 
and/or the packet may be sent to the EMM. The L3 PRO- 
TO field preferably indicates to the egress edge Label 
Switching Router (LSR) on what protocol is present on 
top of the MPLS stack. This information may be used to 
route the packet, e.g., frame, after the last label popping. 
The egress edge LSER preferably is the termination 
LSR of a tunnel. MPLS packets preferably flow through 
a tunnel until they get to an egress edge LSR. The 
egress edge LSR preferably removes the final label and 
handles the resulting packet according to the underlying 
packet type (e.g., normal IP packet). 
[0051 ] The schema Type V 21 8 preferably is a type in 
which customers preferably are identified using both 
source information and destination information. More 
particularly, customers preferably are identified by full 
Border Gateway Protocol (BGP) reverse path lookup. 
[0052] The entry key in schema Type V preferably in- 
cludes Internet Protocol Destination Address (IPDA), In- 
ternet Protocol Source Address (I PSA), Destination Port 
(D PORT), Source Port (S PORT), TCP flag (T) bit and 
invalid (I) bit. In source search mode, IPDA preferably 
is used as a Source IP Address field and the other key 
fields in the search key preferably are set to zero. In des- 
tination search mode, IPDA preferably is used as the IP 
Destination Address and the IPSA preferably is used as 
the IP Source Address. 

[0053] The D PORT preferably is used as the Transfer 
Control Protocol (TCP)/User Datagram Protocol (UDP) 
destination port number and the S PORT preferably is 
used as the TCP/UDP source port number. The T bit 
preferably is set when the TCP protocol is being used 
on top of IP, and preferably is cleared otherwise. The I 
bit preferably is used to indicate invalid condition as in 
other schema types. 



[0054] In the key control fields, the schema Type V 
includes IPDA MASK field and FL bit. Thus, searches 
preferably are controlled by the IPDA MASK used to set 
the IPDA subnet size and FL bit : which may be used, 
5 when set, to mask out the entire IPSA -t- D PORT 4- S 
PORT + T flow spec portion of the entry. 
[0055] The Type V application data preferably in- 
cludes PATH COUNT field, PAYLOAD ID field, PO bit, 
AP bit, ACCT FMT field, CUST ID field, S1 bit ; MR bit. 
io F bit, HS bit, and HD bit. The PAYLOAD ID field, PO bit. 
AP bit, ACCT FMT field, CUST ID field, S1 bit, MR bit, 
F bit, HS bit and HD bit preferably are similar to the cor- 
responding fields and bits in application data for other 
schema types. The PATH COUNT field preferably rep- 
's resents the number of paths available for the route. The 
resultant PAYLOAD ID preferably acts as a base pay- 
load to which the IPSA/IPDA hash may be added mod- 
ulo PATH COUNT 

[0056] The schema Type VI 220 preferably is a type 
20 jn which destination search is used to provide IP multi- 
cast routing. The entry key in schema Type VI preferably 
includes IP Multicast Destination Address (IPMA), 
VLAN ID, IPSA and inhibit bit (I). The schema Type VI 
preferably is used for IP multicast destination searching. 
25 The VLAN ID preferably represents source VLAN for the 
packet, e.g., frame. The schema Type VI preferably has 
MASK in the key control field. The MASK field preferably 
allows specification of the IPSA subnet and may also 
mask out the VLAN ID field. The Type VI application data 
30 preferably includes PAYLOAD field and HD bit, which 
are similarto corresponding field and bit in other schema 
types described above. 

[0057] The schema Type VII 222 preferably is a type 
in which destination search is used to provide full length 

35 Internet Protocol Version 6 (Ipv6) routing. The entry key 
in schema Type VII preferably includes IPv6 Destination 
Address (Ipv6 DA), which is a destination address for 
IPv6 routing. The schema Type VII preferably has IPDA 
MASK in the key control field. The IPDA MASK prefer- 

40 ably is a full width mask. Thus, for example, the IPDA 
MASK (7-bit mask) may be able to mask for full Ipv6 
CIDR support. The Type VII application data preferably 
includes PAYLOAD field and HD bit, which may be sim- 
ilarto corresponding field and bit in other schema types 

45 described above. Up to 128 different next-hops may be 
established from the 7-bit payload ID. 
[0058] FIG. 4 is a flow diagram of identifying and pro- 
viding application data for a packet in one embodiment 
of the present invention. Instep, 250, schema programs 

so are loaded into an application engine, such as, for ex- 
ample, the application engine 150 of FIG. 2. In steps 
252 and 254, respectively, the application engine pref- 
erably receives classification information and header 
data, respectively, of the packet. 

55 [0059] The schema programs preferably uses the 
classification information and the header data of the 
packet to generate one or more keys and key control 
signals in step 256. For example, the schema programs 
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preferably selects the schema to be applied to the pack- 
et based on the classification information and/or the 
header data of the packet. The keys generated by the 
schema programs may also be referred to as search 
keys, since these keys preferably are used to look up or 
search application data for the packet in a schema table 
in step 258. 

[0060] The schema table preferably is included in a 
lookup table, such as, for example, the lookup table 1 54 
of FIG. 2. The schema table preferably includes appli- 
cation data for one or more different schema types, as 
illustrated, for example, as TYPE I through TYPE VII in 
the schema table 200 of FIG. 3. In step 260, the appli- 
cation engine preferably provides the identified applica- 
tion data. The application data preferably is provided to 
an edit module, which may reside within a packet buffer, 
such as, for example, the packet buffer 102 of FIG. 1. 
The edit module preferably edits the packet using the 
application data prior to transmitting the packet as an 
outbound packet. 

[0061] Although this invention has been described in 
certain specific embodiments, many additional modifi- 
cations and variations would be apparent to those 
skilled in the art. It is therefore to be understood that this 
invention may be practiced otherwise than as specifical- 
ly described. Thus, the present embodiments of the in- 
vention should be considered in all respects as illustra- 
tive and not restrictive, the scope of the invention to be 
determined by the appended claims and their equiva- 
lents. 
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counting data., policing data and routing data. 

The packet processing element according to claim 
2 wherein the classification information includes 
one ormore classification data portions, and where- 
in the classification data portions are compared 
against the key portions to select at least one sche- 
ma for the packet. 

The packet processing element according to claim 
1 wherein at least one schema includes one or more 
key portions, one or more key control portions and 
one ormore application data portions, wherein the 
classification information for the packet is applied 
to at least one key portion of a schema in conjunc- 
tion with at least one key control portion of the sche- 
ma to produce application data for the packet from 
at least one application data portion of the schema. 

The packet processing element according to claim 
1 wherein the plurality of schemata include a MAC 
bridging schema. 

The packet processing element according to claim 
1 wherein the plurality of schemata include an IP 
routing schema. 

The packet processing element according to claim 
1 wherein the plurality of schemata include an 
MPLS schema. 



Claims 

1 . A packet processing element for processing a pack- 
et, the packet processing element having a plurality 
of schemata programmed thereon, wherein classi- 
fication information for the packet is used to select 
at least one schema, and wherein the selected 
schema is used to produce application data for the 
packet. 

2. The packet processing element according to claim 
1 wherein at least one schema includes one ormore 
key portions and one or more application data por- 
tions, and the classification information for the pack- 
et is applied to at least one key portion of a schema 
to produce application data for the packet from at 
least one application data portion of the schema. 

3. The packet processing element according to claim 
2 wherein the key portions include at least one data 
selected from group consisting of source data and 
destination data. 

4. The packet processing element according to claim 
2 wherein the application data portions include at 
least one data selected from group consisting of ac- 



10. A method of producing application data for a packet 
using a packet processing element having a plural- 
ity of schemata programmed thereon, the method 

35 comprising the steps of: 

selecting at least one schema using classifica- 
tion information for the packet; and 
producing the application data for the packet 
using the selected schema. 

11. The method of producing application data accord- 
ing to claim 10 wherein at least one schema in- 
cludes one or more key portions and one or more 
application data portions, wherein the step of pro- 
ducing the application data comprises the step of 
applying the classification information for the packet 
to at least one key portion of schema to produce 
application data for the packet from at least one ap- 
plication data portion of the schema. 

12. The method of producing application data accord- 
ing to claim 11 wherein the key portions include at 
least one data selected from group consisting of 
source data and destination data. 

13. The method of producing application data accord- 
ing to claim 1 1 wherein the application data portions 



50 



8 



15 



EP 1 158 724 A2 



16 



include at least one data selected from group con- 
sisting of accounting data, policing data and routing 
data. 

14. The method of producing application data accord- 
ing to claim 1 1 wherein the classification information 
includes one or more classification data portions, 
and wherein the step of applying the classification 
information comprises the step of comparing the 
classification data portions against the key portions 
to select at least one schema for the packet. 

15. The method of producing application data accord- 
ing to claim 10 wherein at least one schema in- 
cludes one or more key portions, one or more key 
control portions and one or more application data 
portions, wherein the step of producing the applica- 
tion data comprises the step of applying the classi- 
fication information for the packet to at least one key 
portion of a schema in conjunction with at least one 
key control portion of the schema to produce appli- 
cation data for the packet from at least one applica- 
tion data portion of the schema. 

16. The method of producing application data accord- 
ing to claim 1 0 wherein the plurality of schemata in- 
clude a MAC bridging schema. 

17. The method of producing application data accord- 
ing to claim 1 0 wherein the plurality of schemata in- 
clude an IP routing schema. 

18. The method of producing application data accord- 
ing to claim 1 0 wherein the plurality of schemata in- 
clude an MPLS schema. 

19. A packet switching controller comprising a process- 
ing engine, the processing engine comprising: 

an element for building a key using classifica- 
tion information for a packet; and 
a lookup table containing one or more schema- 
ta; 

wherein the key is used to select one of the 
schemata for the packet, and the selected 
schema provides application data for the pack- 
et. 

20. The packet switching controller of claim 1 9 wherein 
at least one schema includes a key portion and an 
application data portion, and the key is compared 
against the key portion to lookup the application da- 
ta portion. 

21 . The packet switching controller of claim 1 9 wherein 
the key portion includes at least one data selected 
from group consisting of source data and destina- 
tion -data, and the application data portion includes 



at least one data selected from group consisting of 
accounting data, policing data and routing data. 

22. The packet switching controller of claim 20 wherein 
5 at least one schema includes a key control portion, 

and the key control portion is used in conjunction 
with the key to lookup the application data portion. 

23. The packet switching controller of claim 1 9 wherein 
10 the schemata include at least one schema selected 

from group consisting of a macro access control 
(MAC) bridging schema, an Internet Protocol (IP) 
routing schema and a multi-protocol label switching 
(MPLS) schema. 

15 

24. A method of producing application data for a packet, 
the method comprising the steps of: 

building a key using classification information 
20 for the packet; 

selecting a schema for the packet from a lookup 
table containing one or more schemata; and 
reading the application data from the selected 
schema. 

25 

25. The method of producing application data of claim 

24 wherein at least one schema includes a key por- 
tion and an application data portion, and the key is 
compared against the key portion to lookup the ap- 

30 plication data portion. 

26. The method of producing application data of claim 

25 wherein the key portion includes at least one da- 
ta selected from group consisting of source data 

35 and destination data, and the application data por- 
tion includes at least one data selected from group 
consisting of accounting data, policing data and 
routing data. 

40 27. The method of producing application data of claim 
25 wherein at least one schema includes a key con- 
trol portion, and the key control portion is used in 
conjunction with the key to lookup the application 
data portion. 

45 

28. The method of producing application data of claim 
24 wherein the schemata include at least one sche- 
ma selected from group consisting of a macro ac- 
cess control (MAC) bridging schema, an Internet 

so Protocol (IP) routing schema and a multi-protocol 
label switching (MPLS) schema. 

29. A data communication switch having a backplane 
and a plurality of packet switching controllers inter- 

55 connected over the backplane, at least one packet 
switching controller comprising: 

an application engine having a plurality of 
schemata programmed thereon, wherein classifica- 
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tion information for the packet is used to select at 
least one schema, and wherein the selected sche- 
ma is used to produce application data for the pack- 
et. 

5 

30. The data communication switch of claim 29 wherein 
at least one schema includes one or more key por- 
tions and one or more application data portions, and 
the classification information for the packet is ap- 
plied to at least one key portion of a schema to pro- 10 
duce application data for the packet from at least 
one application data portion of the schema. 
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